ServiceEntry (istio)
GPT-4o.icon
通常、IstioはKubernetesクラスタ内のサービス（Service）しか認識しませんが、ServiceEntryを使うことで外部サービスもIstioによるルーティング、トラフィック管理、監視対象にすることができます。
🔧 役割とユースケース
ServiceEntryを使うと以下のことができます：
1. 外部サービスへの通信を明示的に許可する
例: google.com への通信
2. 外部サービスを仮想的にIstio内のサービスのように扱える
→ VirtualServiceやDestinationRuleでトラフィック制御が可能になる
3. 監視・トレーシングの対象になる
→ Istio Telemetry（例えばPrometheus + Grafana、Jaegerなど）で外部通信を可視化可能
4. Egress Gateway経由での通信を強制できる
→ 通信制御・セキュリティ管理が容易に
🧱 基本的な構文
code:yaml
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: google-api
spec:
hosts:
- "*.googleapis.com"
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: HTTPS
resolution: DNS
主なフィールドの説明
table:_
フィールド 意味
hosts 対象の外部ホスト名。ワイルドカードも使える
location MESH_EXTERNAL なら外部サービス、MESH_INTERNAL なら仮想サービス
ports 通信に使うポートとプロトコル
resolution DNS解決をどう行うか（通常は DNS）
🔐 セキュリティとの関連
Istioの**Outbound Traffic Policy が REGISTRY_ONLY** の場合、ServiceEntryで定義されていない外部ドメインには通信できません。したがって、外部通信を明示的に制御したい場合にServiceEntryは必須です。
💡ユースケース例
1. 外部API（例: Stripe API）への通信
code:yaml
hosts:
- "api.stripe.com"
ports:
- number: 443
name: https
protocol: HTTPS
2. Egress Gateway経由での制御
Egress Gatewayを使う構成と組み合わせると、全外部通信を特定の出口ノードを経由させることが可能です。セキュリティや監査の観点で重要です。
✅ 補足: DNSキャッシュに注意
ServiceEntryでは外部のDNS解決に依存するため、宛先のIPが頻繁に変わるサービスを扱う際は注意が必要です。Istioは内部でEnvoyのDNSキャッシュを使っており、TTLや再解決のタイミングに影響を受けます。